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a. respective defined communications protocol. An object 
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memory may be retrieved and stacked to form a lavene d 
protocol driver in accordance w ith establishe d IgQZQS I 
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betwe en adjacent protocol drivers in tne stacK^nd a com- 
mon database interface is mterposed_ between the protocol 
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DATA STORAGE AND MANAGEMENT nesses and limitations of each. A new technology emerging 

SYSTEM FOR USE WITH A MULTIPLE as a result of recent hardware and software advancements is 

PROTOCOL MANAGEMENT SYSTEM IN A being referred to as Distribution Automation (DA). DA 

DATA ACQUISITION SYSTEM synergizes the functionality, features, and characteristics of 

5 traditional EM and SCADA systems to provide a compre- 

CROSS-REFERENCE TO RELATED hensive automation and data management solution for local 

APPLICATION distribution utilities. Some of the characteristics of a DA 

„_ . i. . . * i tt« i- system include: 

This application is related to U.S. patent application Ser. . <> . • • . i ^ 

No. 08/647,356, filed on even date herewith and assigned to w SC J a a t b ab e ^ gh " Perf ° rmanCe hlSt ° nCal *** confi S uratton 

the assignee of the present invention, now U.S. Pat. No. ' 

5,794,009, issued Aug. 11, 1998. Hi S hl y distributed architecture; 

Flexible communications systems; 

MICROFICHE APPENDIX Management of multi-vendor devices; 

m.. 4* l. j • - t 1( Open protocol development with support of smart devices 

This application contains a microfiche appendix consist- 15 v,. „. r v rr 

a • a u a^+ac (distributed intelligence); 

ing of 3 microfiche and 214 frames. ^ . , . , • 

Dynamic, easy to use graphical user interfaces; 

BACKGROUND OF THE INVENTION Integrates easily with other information systems; 

Uses advanced PC operating systems in place of tradi- 

lliis invention relates to a data acquisition system which 2Q tional main f rame s an d minicomputers; and 

has a plurality of remote data gathering devices each of i ncorpora tes characteristics of both traditional EM and 

which communicates according to a respective defined com- SCADA systems 

munitions protocol and, more particularly to a data stor- ^ Information Superhighway (Iway) represents another 

age and management system for use in such a data acqm- ^ for ^ new generation of Distribut i on a^. 

1 1 " ' 25 mation. The Iway is not just having a connection to the 
Today's utilities have new and ever increasing demands Internet. Several Iway type applications are currently in 
being placed on their information systems. Deregulation, development which affect utility companies, including: 
increasing customer service demands, improving efffcien- direct access to customers for utilities through broadband 
cies (such as "unaccounted for gas"), improving manage- networks, and consolidated energy management systems 
ment of customer demand (such as load balancing) and 30 controlled by marketing companies with buying power. The 
downsizing pressures, force the utilities to find more effi- new opportunities and demands opened up by Iway tech- 
cient ways of collecting and managing their data in order to oologies actually obsolete many (if not all) traditional EM 
compete. These factors exponentially increase the need for SCADA systems. An Iway system is not just another 
timely and accurate operational data. Additionally, new meter reading technology; it is a wide open two-way corn- 
Information Superhighway technologies are opening up a 35 munications link between utilities and their customers, cre- 
vast information resource between utilities and their cus- at ing a whole new world of business opportunities. Iway 
tomers. systems represent the most sophisticated use of Distribution 
Some of the system requirements becoming important to Automation. The demands of an Iway system emphasize the 
utilities include integration of existing information systems, characteristics and capabilities of Distribution Automation, 
use of open systems standards, communications with a 40 The growing use of Electronic Correctors has expanded 
multitude of devices, lower system installation and operat- the definition of a distributed system. Electronic Correctors 
ing costs, scalability for future growth, and ease of use. provide true distributed intelligence, with local logic, 
These requirements also create a new set of challenges, such historical, and auditing information at each site. A system 
as databases which can maintain large historical and con- comprised of several hundred or even a few thousand of 
figuration information on hundreds or even thousands of 45 these devices creates a tremendous logistical problem to deal 
devices, maintaining and implementing both proprietary and with. The central host which maintains these devices must 
new device protocol standards, and applying open systems be able to manage each device's configuration data and 
technologies to create integrated information systems. bring back each device's historical and auditing information 
A utility's information systems can be generally divided mt0 a globally coherent database system, regardless of the 
into the following categories: 50 tv P e °f device used in the field. It is then common for the 

Automated Mapping/Facilities Management (AM/FM); * u at least a C0U P! e of y ears t °* 0D " l l 1 irie f 

, T r . „ historical data (perhaps even to one-hour intervals) for all of 

Geographical Information System (CIS); ^ devices System performance must also be mamtained at 

Electronic Measurement/Supervisory Control and Data a rj times for both user access and incoming data. 
Acquisition (EM/SCADA); and 5S The value of the data obtained by a DA system can 

Customer Information Systems/Financial Information especially be realized if it can be exchanged with other 
Systems (CIS/FIS). information systems throughout the utility. For example, the 

Utilities have invested vast amounts of money to develop Customer and Financial Information systems need accurate 
these information systems and cannot afford to "start over". billing and usage data, and Facilities Management needs 
However, the new demands, as previously discussed, create 60 operational data. Open systems standards such as SQL 
an urgent need for cost effective technology that can utilize (Structured Query Language) and ODBC (Microsoft Open 
most of the prior information systems investments. Database Connectivity) are the basis for easy data exchange 

These requirements and challenges have generated a among diverse systems, 
demand for new technology that integrates a utility's infor- In order to minimize the cost of acquisition and mainte- 

mation sources and combines the strengths of both Elec- 65 nance while not jeopardizing the security of supply, utilities 
tronic Measurement (EM) and Supervisory Control and Data prefer to be able to purchase hardware, software, electronic 
Acquisition (SCADA) systems, while minimizing the weak- measurement, RTUs and other SCADA devices from diverse 



12/12/2002, EAST Version: 1.03.0002 



6,032,154 

3 4 

manufacturers. Some devices are also better at certain func- counts required in a DA system. For example, a DA system 
lions than at others. However, despite the promise of pro- with 500 devices and 25 operational parameters at each 
tocol standards, there are a number of proprietary and device requires 12,500 points. If each device can store 
"de-facto" standard protocols used throughout the industry. 10,000 historical records (not uncommon), then the host 
This diversity in communications makes the goal of mixing 5 system needs to support a minimum of 5 million rows of 
multi-vendor equipment difficult for the utility. There are historical data (and more since the host would normally 
systems on the market which support multiple protocols, maintain more historical data than the remote devices). The 
however, this is usually at a penalty of reduced functionality math is easy, but this simple example is overwhelming for 
Traditional SCADA systems usually do not even provide a a SCADA system which is sold by the number of points, 
mechanism in their protocol systems to support intelligent 10 SCADA packages are presently not designed to easily 
devices which have their own configuration, auditing, and manage or configure such a point count, which requires 
historical data. The results of many of the current protocol individual tag names and room in the memory based "real- 
standards committees will produce new protocol implemen- time" database. 

tations which are more robust than the traditional host Protocol development in present SCADA packages also 
systems have been designed to handle. These aspects prompt 15 does not provide for the tremendous amount of historical 
the need for a more robust open protocol development and auditing data which can be generated by smart devices 
environment which supports easier integration of device such as electronic correctors. SCADA packages offer access 
protocols, including "smart" devices which support true to diverse database engines. However, this is merely a 
distributed processing. cliff-hanger, since a database design for all of this data must 
The demands of a DA system which have been discussed 20 be accomplished to meet the performance and storage needs 
thus far would have traditionally prompted the use of a of the system. This technique allows for a totally unique 
mainframe or minicomputer system. The nature of a DA system for every utility, which translates to support head- 
system requires a tremendous amount of asynchronous aches for both the utility and the system integrator. Again, 
activity, such as highly active communications and database much of this problem comes from the fact that many 
systems. This type of computing can now be accomplished 25 presently available SCADA systems primarily have focused 
through the Client/Server architecture supported by newer on drawing tools and not the data management side of a 
operating systems such as NT, OS/2, and traditional UNIX. system. Common SCADA packages on the market today 
Operating systems like NT and OS/2 provide many of the are, essentially, a set of development tools. The idea of a DA 
advanced capabilities previously found only in UNIX and system is to go beyond a set of development tools to provide 
mainframe operating systems, but at a significantly lower 30 a more robust environment ready to deal with the challenges 
cost to develop and maintain than the traditional systems. A we have presented here, much like the Microsoft OfEce suite 
DA system can now, therefore, be made affordable for the is designed to incorporate solutions for common business 
common Local Distribution Company (LDC), where previ- applications. Some of the advantages a DA system borrows 
ously only the large pipeline and LDC utilities could afford from a SCADA system include alarm handling, advanced 
the expensive custom system solutions. The Client/Server 35 graphics and control capabilities. 

technique also allows a system to be highly scalable to fit EM systems focus primarily on providing consumption 

diverse needs. A network of personal computers running data for billing purposes. Some of the characteristics of an 

database and communication servers potentially has more EM system which would be considered as limitations in a 

computing and throughput power than an expensive main- DA system include: a focus primarily on read-only data 

frame system. 40 translation; lack of device specific configuration capabili- 

By incorporating characteristics found in traditional EM ties; lack of modern object oriented graphics; lack of two- 

and SCADA systems, a DA system now has the edge to be way capabilities if a low-end control site were to be used 

used in diverse installations, where a mix of systems was (such as a nomination control site); some older designs are 

previously required. Common components and features of a not as scalable as the newer open systems designs; limita- 

DA system sound like comparable EM and SCADA fea- 45 tions on protocol development; and limited database storage 

tures: SQL database, communications server, protocol tool capabilities. A DA system corrects these limitations while 

kit, object oriented Graphical User Interface, "real-time" borrowing some EM system advantages such as historical 

database, historical data management, configuration recalculations, data validation, security and audit trails, 

management, recalculation of historical data, auditing, A properly designed DA system can take advantage of 

security, alarming, process graphics, trending, device 50 many proven technologies to provide an even more robust 

management, etc. The big difference here is that these solution for the utility. For example, a properly selected 

features and components should be closely integrated into a client/server database system will provide full transaction 

complete system to duplicate common EM and SCADA processing for multiple users, automatic database recovery, 

features while adding support for the new DA characteris- on-line database backup, roll forward recovery, and scal- 

tics. 55 ability to manage hundreds or thousands of devices with 

To better clarify how a DA system is different from several years of historical data without performance degra- 

traditional EM and SCADAsystems, a discussion of EM and dation. 

SCADA limitations is necessary. Considering the demands A DA communications system should take advantage of 

and challenges presented thus far, a number of problems ISO/OSI (International Standards Organization/Open Sys- 

arise in traditional EM and SCADA systems. SCADA sys- 60 tems Interconnection) standards to allow open development 

terns are most noted for their fancy graphical user interfaces. of protocol drivers. By using the ISO/OSI standards, mul- 

However, the underlying architecture of SCADA often gets tiple protocols and media can be easily maintained in the 

overshadowed by this pretty face. SCADA systems are system without modifying the DA system's architecture, 

typically based on a "real-time" database (RTDB) config- Following these guidelines will also allow easier inclusion 

ured by points. Many SCADA systems have been designed 65 of more sophisticated protocols which are currently being 

for the factory floor, which would have a relatively small defined by diverse standards committees (such as AGA, 

number of points as compared to the logistically large point IEEE/AMRA SCC31, MMS Forum, IEA-60 Home 
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Automation, and joint AMRA/ANSI/CCAC/IEEE working 
group on meter protocol). These protocols will have better 
support of the distributed systems architecture becoming 
prevalent through the use of "smart" devices (such as 
electronic correctors). 5 

A DA system should incorporate advanced graphics and 
drag-and-drop techniques to make system management 
easier. Managing hundreds or thousands of devices (each 
with their own historical data, audit trails, alarms, configu- 
ration parameters, and other items) represents a significant 10 
data presentation challenge. Advanced dynamic object ori- 
ented graphics can be used to represent this data in the form 
of nested folders, tables, and notebooks (similar to OS/2's, 
the Mac's, and Win 95's object oriented user interfaces). 

It is therefore a primary object of the present invention to 15 
provide a data acquisition system satisfying the foregoing 
requirements. 

It is a more specific object of the present invention to 
provide a data storage and management system for such a 
data acquisition system so that data collected from remote 20 
data garnering devices can be stored in an efficient manner 
in a database which is expandable and scalable. 

SUMMARY OF THE INVENTION 

The foregoing and additional objects are attained in 25 
a ccordance with the principles of this invention by provid ing 
a data storage and management system for u se with a da ta 
a cquisition system including a plurality of remote d ata 
gathering devices, wherein each of the plurality of rem ote 
data gathering devices co mmunicates according Ufa res pec- 30 
ti rg"derined communications protocol . The data storage an d 
management system comprises a machine having a memo ry 
co ntaining an object database for storing information r ep- 
resenting a pl urality of device, objects each associated w ith 
a respect ive data gathering device. Each device obj ect 35 
includes at least one protocol stack defining thecomm uni- 
cations prot ocol of the respective data gathering device, at 
l east one poll configuration defining the data to be retrie ved 
f rom the respective data gathering device, and at least^ one 
device data folder defining the groups of jataT oun Jwit hin 40 
the r espective data gather ing device. 

In accordance with an aspect of this invention, the data- 
base further contains information representing the history of 
the remote data gathering device and each device object 
further includes at least one device history which defines 45 
history objects for the respective data gathering device. 

In accordance with another aspect of this invention, each 
protocol stack contains a respective ordered list of protocol 
drivers defined according to ISO/OSI protocol layering 5q 
definitions. 

In accordance with a further aspect of this invention, the 
database stores action data, parameter data and event data 
for each of the defined protocol drivers. 

In accordance with yet another aspect of this invention, 55 
the database stores at least one folder containing a plurality 
of device objects. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing will be more readily apparent upon reading 60 
the following description in conjunction with the drawings 
in which like elements in different figures thereof are iden- 
tified by the same reference numeral and wherein: 

FIG. 1 is a block diagram of a data acquisition system in 
which a multiple protocol management system constructed 65 
in accordance with the principles of this invention is incor- 
porated; 
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FIG. 2 is a conceptual hardware/software block diagram 
of the communications server incorporated in the system of 
FIG. 1; and 

FIGS. 3-U are exemplary entity relationship (ER) dia- 
grams useful for understanding this invention. 

BRIEF DESCRIPTION OF THE APPENDICES 

The appendices included with this application were writ- 
ten as WINDOWS® HELP files to assist a system user in 
understanding the system operation and to develop specific 
protocol stacks. These appendices are as follows: 

APPENDIX A provides an overview of the communica- 
tions server; 

APPENDIX B provides a description of tables in the 
SCAD A database; 

APPENDIX C describes tables in the Security database; 

APPENDIX D describes tables in the Masters database; 

APPENDIX E describes tables in the Audit database; 

APPENDIX F describes tables in the Event database; 

APPENDIX G describes tables in the History database; 

APPENDIX H provides an overview of the Protocol 
Driver Definition, the Protocol Driver Implementation and 
the Protocol Driver Tool Kit; and 

APPENDIX I describes the Database Layer Application 
Programming Interface (API). 

DETAILED DESCRIPTION 

Referring now to the drawings, FIG. 1 shows a data 
acquisition system wherein a plurality of data gathering 
devices 20-1, . . . , 20-N, each with a respective remote 
terminal unit (RTU) 22-1, . . . , 22-N, are each connected via 
an appropriate communications medium 24-1, . . . , 24-N, to 
a central distribution automation system, designated gener- 
ally by the reference numeral 26. The data gathering devices 
20-1, . . . , 20-N may be any suitable device. In the case of 
a gas utility, such devices may be flow meters, electronic 
flow correctors, and the like. The communications media 
24-1, . . . , 24-N may be dedicated wires, telephone lines, 
radio links, and the like. 

The distribution automation system 26 includes a con- 
troller 28 having a plurality of communication ports 30, a 
database memory 32 associated with the controller 28, and 
a media interface 34 connected between the ports 30 and the 
communications media 24-1, . . . , 24-N, which is controlled 
by the controller 28 to establish a connection between a 
particular RTU 22-1, ... , 22-N and a selected one of the 
ports 30, 

Referring to FIG. 2, shown therein is a conceptual 
hardware/software block diagram for the distribution auto- 
mation system 26 of FIG. 1. As shown, the controller 28 
receives commands, such as communications requests, from 
the Navigator application 36, the Scheduler application 38, 
or one of the other applications 40. These applications are 
computer-based, and may reside in the same computer as the 
controller 28 or in an independent free standing computer 
connected via a network. The Navigator 36 is under user 
control, includes a graphical user interface, and is preferably 
WINDOWS® based. By means of the Navigator 36, a user 
can obtain a reading from a specific one of the data gathering 
devices 20-1, . . . , 20-N (FIG. 1), and gain access to the 
database memory 32. The Scheduler 38 provides an auto- 
matic polling function to interrogate the data gathering 
devices 20-1, . . . , 20-N at regularly scheduled intervals and 
update the contents of the database memory 32. The other 
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applications 40 may be developed by the user of the system 
to perform functions specific to that user. 

The database memory 32 is organized as an object data- 
base. Illustratively, a commercially available object 
database, such as that offered by Objectivity/DB may be 
utilized. The database is organized into folders, objects, 
devices, points, etc., as understood in the art, and exemplary 
entity relationships for the database memory 32 are shown 
in FIGS. 3—11. By utilizing an object database as described, 
the database is readily expandable and scalable without any 
of the limitations inherent in a relational database. Thus, for 
example, history data of virtually unlimited size may be 
stored. 

The memory 32 also stores the available protocol drivers. 
In accordance with established standards, such as Interna- 
tional Standards Organization/Open Systems Interconnec- 
tion (ISO/OSI) protocol drivers are stacked, or layered. The 
individual protocol drivers, which function as modular 
building blocks, are stored in the memory 32. Each of the 
RTUs 22-1, . . . , 22-N and its associated communication 
medium 24-1, . . . , 24-N has a predefined communications 20 
protocol for establishing communications. This communi- 
cations protocol is stored in the memory 32, associated with 
the particular RTU, as an ordered list of protocol drivers 
which must be stacked to form the overall communications 
protocol. In addition, the database defines the data to be 25 
retrieved from the particular data gathering device (poll 
configuration), as well as the groups of data found within the 
device (device data folder) (FIG. 7). 

Wh^ri thfr rnntmllpr rP.raiw rS a communication s 
request from one of the applications 36, 38, 40, it sets up a 30 

communications tas k 41- 1 41-N which it assigns to on e 

of the ports 30. B as ed upon the identification of the speci fic 
RTU and communications medium and the associa ted 
o rdered list stored in the database memory 32, the contro ller 
28 establishes a s^ck of protoco l drivers i n accordance wit h 35 
the ISQ/p SI standards, i kacn^bf 'the pYotocol drivers is 



impl emented as a dynamic link library so that multi ple 
stacks sharin g common drivers can be utilized simul ta- 
neously. A universal message interface 42 is provided in 
each stack between adjacent protocol drivers (see APPEN- 40 
DIX H). The protocol drivers have access to the database 
memory 32 through a universal (common) database inter- 
face 44 (see APPENDIX I). 

Under certain circumstances, an RTU 22 is associated 
with two or more defined communications protocol because, 45 
for example, it is coupled to two or more different commu- 
nications media. In that case, the communications request 
will specify the particular communications protocol which is 
to be utilized, and the controller 28 will then set up the 
appropriate protocol driver stack. 50 

In the memory 32, each of the protocol drivers has 
associated therewith a respective object which stores action 
data, parameter data and event data for that protocol driver. 

The aforedescribed system can be configured as a distrib- 
uted data acquisition network comprising a plurality of data 55 
acquisition systems each including a system as shown in 
FIG. 1 and associated with a respective set of data gathering 
devices. 



Accordingly, there has been disclosed a data acquisition 
system which has a plurality of remote data gathering 
devices each of which communicates according to a respec- 
tive defined communications protocol. While an illustrative 
embodiment of the present invention has been disclosed 
herein, it is understood that various modifications and adap- 
tations to the disclosed embodiment will be apparent to 
those of ordinary skill in the art and it is intended that this 
invention be limited only by the scope of the appended 
claims. 

What is claimed is: 

1. A data storage and management system for use with a 
data acquisition system including a plurality of remote data 
gathering devices, each of the plurality of remote data 
gathering devices communicating according to a respective 
defined communications protocol, the data storage and man- 
agement system comprising: 

a machine having a memory containing an object database 
for storing information representing a plurality of 
device objects each associated with a respective data 
gathering device, each device object including: 

(a) at least one protocol stack defining the communi- 
cations protocol of the respective data gathering 
device; 

(b) at least one poll configuration defining the data to be 
retrieved from the respective data gathering device; 
and 

(c) at least one device data folder defining the groups of 
data found within the respective data gathering 
device. 

2. The data storage and management system according to 
claim 1 wherein the database further contains information 
representing the history of the remote data gathering devices 
and each device object further includes at least one device 
history which defines history objects for the respective data 
gathering device. 

3. Hie data storage and management system according to 
claim 1 wherein each of said at least one protocol stack 
contains a respective ordered list of protocol drivers defined 
according to ISO/OSI protocol layering definitions. 

4. The data storage and management system according to 
claim 3 wherein the database stores action data, parameter 
data and event data for each of the defined protocol drivers. 

5. The data storage and management system according to 
claim 1 wherein the database stores at least one folder 
containing a plurality of device objects. 

6. The data storage and management system according to 
claim 1 wherein the database stores in each device object 
information characterizing the respective data gathering 
device, including its manufacturer and model type. 

7. The data storage and management system according to 
claim 1 wherein the database stores for each device object an 
audit device object containing alarm and event information 
for the respective data gathering device. 
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